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DETAILED ACTION 



Claim Rejections - 35 USC § 103 



1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims, 1-3, 8, 20-22, 25, 26, 31-34. and 39-45 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Richter et al. (5,630,061) [Richter] in view of Ducey 
(Multimedia Broadcasting and the internet). 

Regarding claim 1 , Richter discloses a system having ports for receiving 
data (fig. 4, ANDIS MAC drivers 50 and 66), a method for accessing the data by 
applications (fig. 4, Applications 58), the method comprising the steps of: 

Collecting, by miniport (as miniports are simply drivers which interface with 
an NDIS layer, represented here by NDIS Protocol Manager 56, and ANDIS- 
NDIS layer, and the ARCCI 68, in fig. 4), the data from the ports (col. 4, lines 20- 
23); 

Transferring the data to a common application interface (fig. 4, software 
layer comprising 54. 60. 62, 63, 64, and 65. col. 5 line 66 - col. 6 line 22); 

Presenting, by the common application interface, the data to the 
applications (col. 5, lines 4-8). 

Richter fails to disclose the ports are video ports receiving television 
broadcasts with broadcast data. 
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In an analogous art. Ducey teaches datacasting, a fomri of multimedia 
broadcasting which uses existing broadcasting infrastructures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter to include video ports for receiving 
broadcast television with broadcast data, as taught by Ducey, for the benefit of 
providing richer and more involving content to the user of the system. 

Regarding claim 2, Richter and Ducey disclose the method of claim 1, and 
further disclose registering the video ports with the miniport (Richter, col, 4, lines 
55-60). 

Regarding claim 3, Richter and Ducey disclose the method of claim 1 , and 
further disclose receiving a request (wherein the user of applications begins the 
process, Richter, col, 19, lines 54-59) for broadcast data. 

Regarding claim 8, Richter and Ducey disclose the method of claim 1 , and 
further disclose the common application interface is a RawData interface (as the 
MAC Mode has a state for delivering raw or unformatted data, Richter, col. 7. 
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lines 36-44. and as such, the application interface receiving data from the MAC 
driver would be a source of raw, unformatted data, col. 8, lines 65 - col. 9 line 2). 



Regarding claim 20, Richter discloses a system having one or more 
broadcast data sources capable of receiving broadcast data (fig. 4, MAC layer 50 
and 66), a method for collecting the broadcast data from the broadcast data 
sources, the method comprising the steps of: 

Providing a miniport (as miniports are simply drivers which interface with 
an NDIS layer, represented here by NDIS Protocol Manager 56, ANDIS-NDIS 
layer, and the ARCCI 68, in fig. 4) for each broadcast data source (col. 4, lines 
38-60), wherein each broadcast data source is capable of registering with the 
miniport (each MAC must register with the Protocol Manager, col. 4, lines 55-60); 

Receiving a request from an application at the miniport for broadcast data 
from the broadcast data source (applications provide the requests to use the 
network connections, which are broadcast data sources, col. 5, lines 4-8, col. 6, 
lines 4-9 and col. 19, lines 54-65); and 

Collecting the requested broadcast data at the miniport from the broadcast 
data source (this is the basic functionality of the disclosed system, wherein the 
miniport further provides the data to the common application interface for access 
by applications). 

Richter fails to disclose receiving television broadcasts with broadcast 

data. 
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In an analogous art, Ducey teaches datacasting, a fomri of multimedia 
broadcasting which uses existing broadcasting infrastructures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter to include receiving broadcast 
television with broadcast data, as taught by Ducey, for the benefit of providing 
richer and more involving content to the user of the system. 

Regarding claim 21 , Richter and Ducey disclose the method of claim 20, 
and further disclose registering the broadcast data source with the miniport 
(Richter, col. 4, lines 55-60). 

Regarding claim 22, Richter and Ducey disclose the method of claim 20, 
and further disclose requesting (wherein the user of applications begins the 
process, Richter, col. 19, lines 54-59) broadcast data from a broadcast data 
source. 

Regarding claim 25, Richter and Ducey disclose the method of claim 20, 
and further disclose delivering the requested broadcast data to NDIS (clearly 
shown in fig. 4). 
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Regarding claim 26, Richter and Ducey disclose the method of claim 20, 
and further disclose the requested broadcast data is delivered to a RawData 
interface (as the MAC Mode has a state for delivering raw or unfomriatted data, 
Richter, col. 7, lines 36-44, and as such, the application interface receiving data 
from the MAC driver would be a source of raw, unformatted data, col. 8, lines 65 
- col. 9 line 2). 

Regarding claim 31 , Richter discloses a system capable of receiving 
broadcast data, a method for collecting broadcast data from broadcast data 
sources (the broadcast receiving sources are the hardware layer in fig. 4), the 
method comprising the steps of: 

Calling, by the broadcast data source (MAC drivers are identified by the 
port, or channel, they represent, col. 8, lines 34-39), a function of a broadcast 
data source interface having parameters (the primitives are function calls for 
specific data and parameter setting, col. 8, lines 6-18), wherein the broadcast 
data source interface (the MAC drivers 50 and 66, fig. 4) permits broadcast data 
sources to interi'ace with broadcast data source miniports (as miniports are 
simply drivers which interface with an NDIS layer, represented here by NDIS 
Protocol Manager 56, and ANDIS-NDIS layer, and the ARCCI 68, in fig. 4); and 
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Executing the function by the broadcast data source interface (for 
example, calling the Register_PCM function assigns a MAC port to the PCM, col. 
8. lines 34-44). 

Richter falls to disclose receiving television broadcasts with broadcast 

data. 

In an analogous art, Ducey teaches datacasting, a form of multimedia 
broadcasting which uses existing broadcasting infrastmctures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter to include receiving broadcast 
television with broadcast data, as taught by Ducey, for the benefit of providing 
richer and more involving content to the user of the system. 

Regarding claim 32, Richter and Ducey disclose the method of claim 31 , 
and further disclose the function comprises Register and the parameter 
comprises VideoPort (the Register_PCM function assigns a MAC port, which 
handles broadcast data from incoming television broadcasts making it a video 
port, as taught by Ducey, to the PCM, col. 8, lines 34-44). 



Application/Control Number: 09/526,579 Page 8 

Art Unit: 2611 

Regarding claim 33, Richter and Ducey disclose the method of claim 31 , 
and further disclose the function comprises DeRegister [Release_PCM] and the 
parameter comprises SourcingHandle [PortJD] (col. 8. lines 48-57). 

Regarding claim 34, Richter and Ducey disclose the method of claim 31 , 
and further disclose the function comprises Indicate [Retrieve_PPI_Status] and 
the parameter comprises Indication [returns PPI status] (col. 9, lines 7-19). 

Regarding claim 39, Richter discloses a system capable of receiving 
broadcast data (from LAN 46 and WAN in fig. 4), a method for providing the 
broadcast data to applications (fig 4, applications 58), the method comprising the 
steps of: 

Calling, by the applications, a function having parameters of a RawData 
interface (same function calls and parameters as with the disclosed NDIS 
extensions, but with a another module wherein the data is passed unformatted, 
col. 8 line 65 - col. 9 line 6), wherein the RawData interface permits the 
applications to interface with a RawData module (col. 8, lines 65-67); and 

Executing the function by the RawData interface (an inherent feature, 
because when a function is called, that function is executed). 

Richter fails to disclose receiving television broadcasts with broadcast 

data. 
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In an analogous art, Ducey teaches datacasting, a fonn of multimedia 
broadcasting which uses existing broadcasting infrastructures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richterto include receiving broadcast 
television with broadcast data, as taught by Ducey, for the benefit of providing 
richer and more involving content to the user of the system. 

Regarding claim 40, Richter and Ducey disclose the method of claim 39, 
and further disclose the function comprises SelectRawData [Register_Null_DLC] 
and the parameter comprises VideoPort [PortJD] (wherein the function 
establishes a connection for unformatted data through a specific port [which 
handles broadcast data from incoming television broadcasts making it a video 
port, as taught by Ducey] Richter, col. 10, lines 31-37). 

Regarding claim 41, Richter and Ducey disclose the method of claim 39, 
and further disclose the function comprises SelectRawData [Register_Null_DLC] 
and the parameter comprises RawDataHandle [PortJD] (col. 10, lines 31-48). 
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Regarding claim 42, Richter discloses a computer program product for 
implementing, in a system capable of receiving broadcast data (from LAN 46 and 
WAN in fig, 4), a method for collecting the broadcast data from broadcast data 
sources (hardware layer in fig. 4), the computer program product comprising: 

A computer readable medium (fig. 2. RAM 24) carrying computer 
executable instructions for implementing the method (col, 3, lines 43-53), wherein 
the computer executable instructions comprise program code means for: 

Calling, by a broadcast data source (MAC addresses), a function of a 
broadcast data source interface (MAC drivers, fig. 4), the function having 
parameters (col, 8, lines 7-26), wherein the broadcast data source interfaces the 
broadcast data sources with broadcast data source miniports (as miniports are 
simply drivers which interface with an NDIS layer, represented here by NDIS 
Protocol Manager 56, and ANDIS-NDIS layer, and the ARCCI 68, in fig, 4), 

Richter fails to disclose receiving television broadcasts with broadcast 

data. 

In an analogous art. Ducey teaches datacasting, a form of multimedia 
broadcasting which uses existing broadcasting infrastructures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the computer program product disclosed by Richter to include 
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receiving broadcast television with broadcast data, as taught by Ducey, for the 
benefit of providing richer and more involving content to the user of the system. 

Regarding claim 43, Richter and Ducey disclose the computer program 
product of claim 42, and further disclose the function comprises register 
[Register_PCM] and the parameter comprises VideoPort [Port_ID] (wherein the 
data port receives broadcast data from a television broadcast [making it a video 
port, as taught by Ducey] col. 8, lines 34-47). 

Regarding claim 44, Richter and Ducey disclose the computer program 
product of claim 42, and further disclose the function comprises deregister 
[Release_PCM] and the parameter comprises SourcingHandle [Port_ID] (col. 8, 
lines 48-57). 

Regarding claim 45, Richter and Ducey disclose the computer program 
product of claim 42, and further disclose the function comprises indicate 
[Retrieve_PPI_Status] and the parameter comprises Indication 
[PPI_Status_Pointer] (wherein the function call returns the status of the port 
interface to the place indicated by the status pointer, col. 9, lines 7-20). 
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3. Claims 4-6 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Richter and Ducey as applied to claims 1 and 20 above, and further in view of 
Jones et al. (6.216,173) [Jones]. 

Regarding claim 4, Richter and Ducey disclose the method of claim 1 , but 
fail to disclose separating broadcast data that complies with a protocol from 
broadcast data that does not comply with the protocol. 

In an analogous art, Jones teaches receiving data from multiple networks 
for use by multiple applications (col. 40, lines 52-67 and col. 41 . lines 33-43), 
wherein data is intelligently converted as necessary (col. 40, lines 64-67), so 
when data which conforms to the protocol required by the network or application 
is received, no conversion takes place, but when the data does not conform to 
the necessary protocol, then the data is converted. This naturally means that 
received data is separated into objects or streams which comply with the 
necessary protocol from data which does not. This would allow users to receive 
a broad range services to be provided to users of many types of applications and 
devices (col. 43, lines 21-40). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter and Ducey to include separating 
broadcast data that complies with a protocol from broadcast data that does not 
comply with the protocol, as taught by Jones, for the benefit of ensuring that the 
data being received is useable by the application, as data which does not comply 
with the protocol would require further processing. 
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Regarding claim 5, Richter, Ducey, and Jones disclose the method of 
claim 4 as applied above, but fall to disclose the protocol is UDP/IP. 

Jones further teaches receiving and viewing data at personal computers 
(using such applications as a web browser or Java applet) which originated from 
a video network and is make available in UDP format over an IP network (col. 43, 
lines 30-39), wherein UDP/IP fomiat is a more efficient means of handling and 
transporting data than the more common TCP/IP format, requiring less overhead 
bits, and IP is widely compatible with many applications, as any application which 
supports internet data recognizes IP. 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter, Ducey, and Jones to include 
UDP/IP, as further taught by Jones, for the benefit of accessing the data using an 
efficient and widely compatible protocol. 

Regarding claim 6, Richter, Ducey, and Jones disclose the method of 
claim 4, and further disclose appending headers to the broadcast data which 
does not conform to the protocol such that the data does conform to the protocol 
(an inherent step, as the process of converting the fonnat of data to be transmit 
over a network or used by an application requiring a new protocol is to add new 
header data, Jones, col. 40, lines 64-67). 
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Regarding claim 23, Richter and Ducey disclose the method of claim 20, 
but fail to disclose differentiating broadcast data that complies with a protocol 
from broadcast data that does not comply with the protocol and encapsulating 
the broadcast data the does not comply with the protocol with headers such that 
the broadcast data complies with the protocol. 

In an analogous art, Jones teaches receiving data from multiple networks 
for use by multiple applications (col. 40, lines 52-67 and col. 41, lines 33-43), 
wherein data is intelligently converted as necessary (col. 40, lines 64-67), so 
when data which conforms to the protocol required by the network or application 
is received, no conversion takes place, but when the data does not conform to 
the necessary protocol, then the data is converted. This naturally means that 
received data is separated into objects or streams which comply with the 
necessary protocol from data which does not. The step of conversion inherently 
includes encapsulating the broadcast data by adding headers to the data such 
that it complies with the desired protocol (known as transcoding). This would 
allow users to receive a broad range services to be provided to users of many 
types of applications and devices (col. 43, lines 21-40). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter and Ducey to include separating 
broadcast data that complies with a protocol from broadcast data that does not 
comply with the protocol and encapsulating the broadcast data that does not 
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comply with headers such that it does, as taught by Jones, for the benefit of 
ensuring that all received data is available to the applications. 

4. Claim 7 is rejected under 35 U.S.C. 103(a) as being unpatentable over Richter 
and Ducey as applied to claim 1 above, and further in view of Mohammed (6,041,356). 

Regarding claim 7, Richter and Ducey disclose the method of claim 1, but 
fail to disclose the common application interface is Winsock. 

In an analogous art, Mohammed teaches accessing received data through 
Winsock (col. 5, lines 64 - col. 6 line 2), wherein Winsock is an application 
interface designed specifically for accessing data from an IP layer which has 
been received through an NDIS layer. 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter and Ducey to include Winsock, as 
taught by Mohammed, for the benefit of accessing the broadcast data through a 
widely recognized and highly efficient application interface designed specifically 
for accessing data received through an NDIS layer (wherein utilizing NDIS for 
flexibility is established by Richter). 

5. Claims 9, 10, and 24 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Richter and Ducey as applied to claims 1 and 20 above, and further in view of 
Stalker (US 2002/009186 A1). 
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Regarding claims 9 and 10, Richter and Ducey disclose the method of 
claim 1 , but fail to disclose the common application interface is a presenter which 
formats and instance filters the broadcast data. 

In an analogous art. Stalker teaches a presenter (fig. 2, data access 
system 30, paragraph 16, lines 1-4) which fomnats (using data source processors 
42, paragraph 17) and filters (paragraph 21) incoming broadcast data, for the 
benefit of preparing the data for the requesting applications (paragraph 19) and 
processing only requested data (paragraph 21, lines 1-3). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter and Ducey to include a presenter 
which formats and instance filters received broadcast data, as taught by Stalker, 
for the benefit of properly preparing the received broadcast data for the 
requesting applications and more efficiently processing the incoming broadcast 
data by processing only the requested data. 

Regarding claim 24, Richter and Ducey disclose the method of claim 20, 
but fail to disclose separating requested broadcast data from unrequested 
broadcast data. 

In an analogous art, Stalker teaches filtering received broadcast data so 
that only requested broadcast data is processed (paragraph 21 ) in order to more 
efficiently process incoming data. 
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It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter and Ducey to include separating 
requested broadcast data from unrequested broadcast data, as taught by 
Stalker, for the benefit of more efficiently processing the received broadcast data. 



6. Claims 1 1 , 14, 16-19, 27, 29. 30, 35-38, and 46-50 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Richter, Ducey, and Stalker. 

Regarding claims 1 1 , 27, and 50, Richter discloses a system (and 
computer program product) capable of receiving broadcast data (through ANDIS 
MAC drivers 50 and 66, fig. 4), a method for presenting broadcast data to an 
application (fig. 4, Applications 58), the method comprising the steps of: 

Capturing the broadcast data by a broadcast data source (50 and 66 
receive data, col. 4, lines 20-23); 

Delivering the broadcast data to a miniport (as miniports are simply drivers 
which interface with an NDIS layer, represented here by NDIS Protocol Manager 
56, and ANDIS-NDIS layer, and the ARCCI 68, in fig. 4); and 

Transferring the broadcast data from the miniport to a common application 
interface (fig. 4, software layer comprising 54, 60, 62, 63, 64, and 65, col. 5 line 
66 - col. 6 line 22). 

Richter fails to disclose the broadcast data is embedded into television 
broadcasts and retrieving the broadcast data from the common application 




Application/Control Number: 09/526.579 Page 18 

Art Unit: 2611 

interface by a presenter which prepares the broadcast data for presentation to 
the application. 

In an analogous art, Ducey teaches datacasting, a form of multimedia 
broadcasting which uses existing broadcasting infrastructures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method and computer program product disclosed by Richter to 
include embedding the broadcast data into television broadcasts as taught by 
Ducey, for the benefit of providing richer and more involving content in television 
broadcasts. 

In an analogous art. Stalker teaches a presenter (fig. 2, data access 
system 30, paragraph 16, lines 1-4) which receives broadcast information and 
prepares (formats using data source processors 42, paragraph 17, and filters 
[paragraph 21]) the incoming broadcast data, for the benefit of making the data 
immediately accessible by the requesting applications (paragraph 19). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method and computer program product disclosed by Richter and 
Ducey to include a presenter which prepares received broadcast data, as taught 
by Stalker, for the benefit of making the received broadcast data immediately 
available for the requesting applications. 
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Regarding claim 14, Richter, Ducey, and Stalker disclose tlie method of 
claim 1 1 , and further disclose the step of transferring the broadcasts data further 
comprises the steps of: 

Transferring the broadcast data from the miniport to NDIS (as seen in fig. 
4, where the data received through the MAC layer 50 and 66 is transferred to the 
protocol drivers which have been bound to each MAC through the protocol 
manager, col. 4, lines 55-60); 

Transferring the broadcast data from NDIS to a protocol (each PD 54 is a 
protocol, col. 4, lines 38-45); and 

Transferring the broadcast data from the protocol to the common 
application interface (where it is accessed by applications, col. 5 line 66 - col. 6 
line 9). 

Regarding claims 16 and 29, Richter, Ducey, and Stalker disclose the 
method of claim 1 1 , and further disclose the common application interface is a 
[BDS] RawData interface [wherein BDS stands for Broadcast Data Service, the 
feature taught by Ducey] (the MAC Mode has a state for delivering raw or 
unformatted data, Richter, col. 7, lines 36-44, and as such, the application 
interface receiving data from the MAC driver would be a source of raw, 
unfonnatted data, col. 8, lines 65 - col. 9 line 2). 
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Regarding claims 17 and 30, Richter, Ducey, and Stalker disclose the 
method of claim 1 1 , and further disclose the step of preparing the broadcast data 
further includes the presenter formats (Stalker, using data source processors 42, 
paragraph 17) and instance filters (Stalker, paragraph 21) the broadcast data. 

Regarding claim 18, Richter, Ducey, and Stalker disclose the method of 
claim 1 1 , and further disclose receiving a request from the application for the 
broadcast data (wherein the user of applications begins the process, Richter, col. 
19, lines 54-59) through the miniport (because all communications between the 
receiving hardware and the NDIS layer pass through miniports). 

Regarding claim 19, Richter, Ducey, and Stalker disclose the method of 
claim 1 1 , and further disclose the enabling the broadcast data source (binding 
the MAC to a protocol or channel, Richter, col. 8, lines 34-44). 

Regarding claims 35 and 46, Richter discloses a system (and computer 
program product) capable of receiving broadcast data (from LAN 46 and WAN 
found in fig. 4), a method for presenting the broadcast data to applications (fig. 4, 
applications 58), the method comprising retrieving broadcast data from a 
common application interface (Connection Management Interface API, col. 6, 
lines 4-9). 
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Richter fails to disclose receiving television broadcasts having broadcast 
data and calling by the applications a function, having a parameter, of a 
presenter interface, wherein the presenter interface provides the applications 
access to a broadcast data presenter, the broadcast data presenter being 
capable of retrieving and preparing broadcast data and executing the function by 
the presenter interface. 

In an analogous art, Ducey teaches datacasting, a form of multimedia 
broadcasting which uses existing broadcasting infrastructures to transport digital 
information, both related and unrelated to the conventional programming, 
providing richer and more involving content in broadcast programming (pages 5- 
6, under the heading Multimedia broadcasting, paragraphs 1 and 2). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter to include receiving television 
broadcasts with broadcast data as taught by Ducey, for the benefit of providing 
richer and more involving content in television broadcasts. 

In an analogous art, Stalker teaches a presenter (fig. 2, data access 
system 30, paragraph 16, lines 1-4) which receives broadcast information 
(paragraph 14, lines 1-5), wherein an application (fig. 4, application 34) calls a 
function (paragraph 16, lines 7-11) having parameters (paragraph 19, lines 6-10) 
of a presenter interface (fig. 4, interest manager 36), wherein the presenter 
interface provides the applications access to the presenter (paragraph 16), the 
presenter being capable of retrieving data from a source (or sources) of data 
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(paragraph 17) and prepares the data for the application (paragraph 17 and 
paragraph 18, lines 1-4), and executes the function by the presenter interface 
(paragraph 19, lines 11-13), providing applications with requested data without 
requiring each application to individually retrieve the broadcast data, streamlining 
the process and making it more efficient. 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method and computer program product disclosed by Richter and 
Ducey to include calling by the applications a function, having a parameter, of a 
presenter interface, wherein the presenter interface provides the applications 
access to a broadcast data presenter, the broadcast data presenter being 
capable of retrieving broadcast data, prepared by a broadcast presenter, and 
executing the function by the presenter interface, as taught by Stalker, for the 
benefit of providing applications with requested data through a presenter 
interface, so that each application is not required to individually retrieve the 
broadcast data, streamlining the method and making it more efficient. 

Regarding claims 36 and 47, Richter, Ducey, and Stalker disclose the 
method and computer program product of claims 35 and 46, and further disclose 
the function comprises SelectData (Stalker, paragraph 19, lines 1-3) and the 
parameters comprise DataType [module id] and VideoPort [source id] (paragraph 
19, lines 6-10 [as the source ports receive broadcast data from television 
broadcasts, as taught by Ducey]). 
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Regarding claims 37 and 48, Richter, Ducey, and Stalker disclose the 
method and computer program product of claims 35 and 46. but fail to disclose 
the function comprises DeselectData and the parameter comprises 
PresenterHandler, 

Examiner takes Official Notice that it is old and well known for user*s of 
applications to cancel actions taken, such as a request for data, for instance, if 
the user of the application changes his or her mind concerning a particular 
request, it is a common feature of applications to cancel said request. 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter, Ducey, and Stalker to include the 
function DeselectData and the parameter PresenterHandler, wherein the 
DeselectData function cancels the selection of previously selected data, and the 
PresenterHandler parameter identifies the data being deselected, for the benefit 
of providing to user's the option of canceling a request for a particular set of data 
if said user changes his or her mind. 

Regarding claims 38 and 49, Richter, Ducey, and Stalker disclose the 
method and computer program product of claims 35 and 46, and further disclose 
the function comprises ReleaseData and the parameters comprise 
PresenterHandle and DeliveryLocation, This function call and parameters are 
inherently necessary, because a requesting application must not only identify 
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what data it wishes to receive, but must also identify itself so that the data, when 
received, is properly directed to the correct application. 



7. Claims 12 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Richter, Ducey, and Stalker as applied to claim 1 1 above, and further in view of 
Jones. 

Regarding claim 12, Richter, Ducey, and Stalker disclose the method of 
claim 1 1 , but fail to disclose differentiating broadcast data that complies with a 
protocol from broadcast data that does not comply with the protocol and 
encapsulating the broadcast data the does not comply with the protocol with 
headers such that the broadcast data complies with the protocol. 

In an analogous art, Jones teaches receiving data from multiple networks 
for use by multiple applications (col. 40, lines 52-67 and col. 41. lines 33-43), 
wherein data is intelligently converted as necessary (col. 40, lines 64-67), so 
when data which conforms to the protocol required by the network or application 
is received, no conversion takes place, but when the data does not conform to 
the necessary protocol, then the data is converted. This naturally means that 
received data is separated into objects or streams which comply with the 
necessary protocol from data which does not. The step of conversion inherently 
includes encapsulating the broadcast data by adding headers to the data such 
that it complies with the desired protocol (known as transcoding). This would 
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allow users to receive a broad range services to be provided to users of many 
types of applications and devices (col. 43. lines 21-40). 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter. Ducey. and Stalker to include 
separating broadcast data that complies with a protocol from broadcast data that 
does not comply with the protocol and encapsulating the broadcast data that 
does not comply with headers such that it does, as taught by Jones, for the 
benefit of ensuring that all received data is available to the applications. 

Regarding claim 13, Richter, Ducey, Stalker, and Jones disclose the 
method of claim 12 as applied above, but fail to disclose the protocol is UDP/IP. 

Jones further teaches receiving and viewing data at personal computers 
(using such applications as a web browser or Java applet) which originated from 
a video network and is make available in UDP format over an IP network (col. 43, 
lines 30-39), wherein UDP/IP format is a more efficient means of handling and 
transporting data than the more common TCP/IP format, requiring less overhead 
bits, and IP is widely compatible with many applications, as any application which 
supports internet data recognizes IP. 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter, Ducey, Stalker, and Jones to 
include UDP/IP, as further taught by Jones, for the benefit of accessing the data 
using an efficient and widely compatible protocol. 
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8. Claims 1 5 and 28 are rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over Richter, Ducey, and Stalker as applied to claims 1 1 and 27 above, and further in 
view of Mohammed. 

Regarding claims 15 and 28, Richter, Ducey, and Stalker disclose the 

method of claims 1 1 and 27, but fail to disclose the common application interface 

is Winsock. 

In an analogous art, Mohammed teaches accessing received data through 
Winsock (col. 5, lines 64 - col. 6 line 2), wherein Winsock is an application 
interface designed specifically for accessing data from an IP layer which has 
been received through an NDIS layer. 

It would have been obvious at the time to a person of ordinary skill in the 
art to modify the method disclosed by Richter, Ducey, and Stalker to include 
Winsock, as taught by Mohammed, for the benefit of accessing the broadcast 
data through a widely recognized and highly efficient application interface 
designed specifically for accessing data received through an NDIS layer (wherein 
utilizing NDIS for flexibility is established by Richter). 



Conclusion 

9. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. Bergler (5,572,675) who teaches an integrated service, protocol 
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independent API, and Mohammed et al. (6,157,965) who teaches a method for 

interfacing applications to network driver Interface device drivers. 

10. The following are suggested formats for either a Certificate of Mailing or 
Certificate of Transmission under 37 CFR 1 .8(a). The certification may be Included with 
all correspondence concerning this application or proceeding to establish a date of 
mailing or transmission under 37 CFR 1 .8(a). Proper use of this procedure will result in 
such communication being considered as timely if the established date Is within the 
required period for reply. The Certificate should be signed by the individual actually 
depositing or transmitting the correspondence or by an individual who, upon information 
and belief, expects the correspondence to be mailed or transmitted In the normal course 
of business by another no later than the date indicated. 
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Certificate of Mailing 

I hereby certify that this correspondence is being deposited with the United States Postal Service with 
sufficient postage as first class mail in an envelope addressed to: 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



(Date) 

Typed or printed name of person signing this certificate: 



Signature: 

Certificate of Transmission 

I hereby certify that this correspondence is being facsimile transmitted to the United States Patent and 

Trademark Office, Fax No. (703) - on . 

(Date) 

Typed or printed name of person signing this certificate: 



on 



Signature: 



Please refer to 37 CFR 1 .6(d) and 1 .8(a)(2) for filing limitations concerning 
facsimile transmissions and mailing, respectively. 
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1 1 . Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Dominic D Saltarelli whose telephone number is (703) 
305-8660. The examiner can normally be reached on M-F 10-7. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Vivek Srivastava can be reached on (703) 305-4038. The fax phone 
number for the organization where this application or proceeding is assigned is 703- 
872-9306. 

infomriation regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

Dominic Saltarelli 
Patent Examiner 
Art Unit 2611 
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